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ABSTRACT 

Defining nontrivial class instances for irregular and exponen¬ 
tial datatypes in Haskell is challenging, and as a solution 
it has been proposed to extend the language with quanti¬ 
fied class constraints of the form Va. C a => C' (f a) in the 
contexts of instance declarations. We show how to express 
the equivalent of such constraints in vanilla Haskell 98, but 
their utility in this language is limited. We also present a 
more flexible solution, which relies on a widely-supported 
language extension. 
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1. INTRODUCTION 

Contexts in Haskell instance declarations constrain type 
variables appearing in the defined instance type. As an ex¬ 
ample (adapted from Ralf Hinze and Simon Peyton Jones [4]) 
consider the class of types with representation in binary: 
data Bit = Zero \ One 
class Binary a where 
showBin :: a —> [Bit] 
instance Binary Bit where 
showBin = (: []) 

An instance of Binary for lists could be defined as follows: 
instance Binary a => Binary [a] where 
showBin = concat . map showBin 
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This instance declaration actually represents an “instance 
generator,” or a proof that the type [a] is an instance of 
Binary whenever a is; hence the type variable a can be 
thought of as universally quantified, and the instance dec¬ 
laration as a proof of Va. Binary a =>■ Binary [a], where the 
quantification over a is made explicit. 

Explicit quantification is not allowed in Haskell contexts, 
and typically it is unnecessary, because usually the construc¬ 
tion of only finitely many class instances must be ensured in 
order to type-check a Haskell expression. In these cases, as 
in the above example, the range of the quantifier would in¬ 
clude both the class context of the declaration and the type 
being declared as an instance. 

However the ability to express polymorphic recursion in 
Haskell (directly or in the guise of recursive instance declara¬ 
tions) introduces some cases when specifying class contexts 
with local quantifiers appears to be the only solution. One 
of these cases occurs when in order to type-check an instance 
declaration, we have to prove the existence of infinitely many 
instances, as in instances of the following types (an example 
due to David Feuer and Simon Peyton Jones [6], arising in 
the context of Chris Okasaki’s use of irregular datatypes to 
represent square matrices in [8]): 

newtype Two fa = Two (f (fa)) 
data Sqfa = M a (fa) \ E {Sq {Two f) a) 

In order to define the binary representation for expressions 
of type Sqfa in terms of their components, we need types 
a and fa to be instances of Binary. 
instance (Binary a, Binary (fa), ...)=> Binary (Sq f a) 

where 

showBin (M x xs) = showBin x -H- showBin xs 
showBin (E p) = showBin p 
Let us ignore the fact that the constraint on fa is not in 
Haskell 98 (allowing type expressions in class constraints 
hinders instance inference); several implementations sup¬ 
port such constraints. This instance declaration is not yet 
complete—additional context, denoted by ellipsis, is needed 
for the case when the term is constructed with E\ we need 
an instance of Binary for Sq (Two f) a, which is a substitu¬ 
tion instance of the very type for which we are defining the 
current instance. The instance inference algorithm assumes 
the current declaration is already available, so we can in¬ 
stantiate the known thus far context of the declaration to 
find out that we need the instance Binary (Two f a): 
instance Binary (f (f a)) => Binary (Two f a) where 
showBin (Two x) = showBin x 




Now we run into the real problem in defining the instance 
Binary (Sq f o): Since the constraint Binary (f (/ a)) must 
be included in the ellipsis, the instantiation with Two f for 
/ in turn requires the instance Binary (Sq (Two (Two /)) a), 
hence the constraint Binary (f (f (f (f a)))) must be added, 
etc., ad infinitum 1 —meaning that no finite proof exists that 
an instance Binary (Sq f a) can be constructed. 

In other cases a finite number of instances would suffice for 
checking the instance declaration, but no finite instance con¬ 
struction is possible. This happens in the following example 
(adapted from Peyton Jones’ message [5] and his paper with 
Hinze [4]): 

data GRose f a m ■GBranch a(f (GRose f a)) 

instance (Binary a, Binary (f (GRose f a))) -- illegal 
=> Binary (GRose f a) where 
showBin (GBranch x xs) = showBin x -H- showBin xs 

The constraint Binary (f (GRose f a)), required by the sec¬ 
ond application of showBin, is not legal in Haskell 98. Im¬ 
plementations which allow it (in extensions) accept this dec¬ 
laration; however, except in degenerate cases for /, no in¬ 
stances Binary (GRose f a) can actually be created. Con¬ 
sider the example of / =% £]. To create an instance of 
Binary for GRose [] a, the compiler must first create one for 
[GRose [] a]; however according to the instance declaration 
for Binary [a] it must first create an instance for GRose [] a, 
causing the instance generation to diverge. 

The problems with generating an unbounded number of 
instances and with mutually dependent instances could be 
resolved if, instead of trying to describe them all, we could 
describe a recipe for creating them. Hinze and Peyton Jones 
observe this in [4], and point out that “no ordinary Haskell 
context will do” and that a solution would be to allow “poly¬ 
morphic predicates” of the form 

ctx ::= Vo. (eta i, ..., ctx n ) =$> Ct 

where C is a class name and t is a type, in instance contexts. 
(We use the term “quantified constraints” instead of “poly¬ 
morphic predicates.”) In the above examples the necessary 
constraint is 

Vo. Binary a => Binary (f a) 

Thus the instance declaration for GRose takes the form 

instance (Binary a, Wb. Binary b => Binary (fb)) 

:<=!*■ Binary (GRose f a) where 
showBin (GBranch x xs) = showBin x -H- showBin xs 

Now the required instance for / (GRose f a) can be con¬ 
structed by instantiating the quantified constraint with the 
type GRose f a and applying the result to the current in¬ 
stance. Similarly the instance Binary (f a), needed in the 
declaration of Binary (Sq f a) in the earlier example, can be 
constructed from Binary a (instead of required in the con¬ 
text), thus cutting the infinite chain of required instances. 

In this paper we show that Haskell’s constructor classes 
offer a way to express the equivalent of quantified constraints 
in vanilla Haskell 98. The full compliance with the language 

x In contrast, other uses of polymorphic recursion require a 
statically unbounded number of instances to be constructed 
at run time, but only a finite number of class constraints, so 
they are correct programs in Haskell 98. 


comes at the price of non-local flow-based program transfor¬ 
mations, which limit its scope of applicability. We also show 
how to achieve closer simulation of the uses of quantified con¬ 
straints when programming with the widely-supported lan¬ 
guage extension with variable constructor heads in declared 
instance types. While not covering the range of applications 
targeted by the proposal for direct language support, these 
solutions can be applied successfully to problems which have 
received attention in the community [4, 5, 6, 7, 10], and yield 
programs in supported Haskell. 

2. DICTIONARIES 

AND TYPE EQUIVALENCES 

A quantified constraint Vo. C a => G (f a) indicates the 
requirement that an “instance generator” for class C is avail¬ 
able for type /. Our goal is thus to allow the context of one 
instance generator (e.g. for the instance Binary (GRose fa)) 
to request the existence of another instance generator (e.g. 
that for V6. Binary b => Binary (f b)), whereas Haskell only 
allows instances to be requested. With this observation, let 
us look at the semantics of instances and generators and try 
to find a correspondence. 

The standard semantics of Haskell type classes is given 
by translating the language into one with explicit passing 
of dictionaries [9] — records containing the methods of the 
required instances. Thus a class declaration 

class C a where nu :: cty t 

gives rise to a type constructor G = \a :: k. :: [ch/JaJ 
in a standard extension of F w [2] with records (tuples): 

kinds k ::= * | k —* n' 

types t ::= a \ \a :: k.t \ tt' \ t —> r' | Va :: k. r 
| irm :: n} \ ... 

terms e ::= x \ Xx :: r. e | ee' | Aa :: k. e \ e [r] 

| imi = ei y \e.m\ ... 

where x ranges over term variables, a and b range over type 
variables, and m ranges over labels. 2 The types [ch/Ja are 
the translations of cty i , which are Haskell types with con¬ 
texts; the most important feature of the translation is that it 
turns class contexts into types of dictionaries as arguments, 
and quantifies over all free type variables other than a: 

[(Cj (ajtf)) =» t]„ = V6. G :j (aj Tj) -* t 

where 6 is a sequence of all type variables in the set {aj} U 
FV(tj) U FV(t) — {a}, i.e. all type variables free in the type 
(including the contexts) but a. Note that the metavariable t 
ranges over simple Haskell types; we gloss over the details of 
their translation by assuming they are a subset of the target 
language types r. 

An “instance generator” declaration, of the form 
instance (Cj aj) Jp Cr where to* — c* 
can be translated as a “dictionary generator” term 
dg = Ab.Xdj :: CjOjArm = [ei]^. a .> 

2 We use an overloaded notation A for sequences of terms of 
the syntactic category ranged over by A: the separators be¬ 
tween the terms in the sequence should be inferred from the 
context. If each of the terms A has component subterms we 
need to refer to, they are all indexed with the same subscript; 
in some cases these subterms are themselves sequences. 




where the translation [•] a , replaces all uses of the in¬ 
stances Cj dj by operations on the corresponding dictiona¬ 
ries dj. Details of this translation are omitted, because they 
are not important for us at this point; important is the type 
of the term dg: 

dg :: V6. Cj aj —> irrii :: rf} 

Thus, in terms of this translation, our goal is to make dic¬ 
tionary generators like dg take parameters of the type of dg. 
However the translation obviously only allows dictionaries 
as parameters of dictionary generators. 

But perhaps it is possible to have a dictionary parameter 
whose type is isomorphic to the type of a generator? 

The difference between dictionaries and dictionary gen¬ 
erators is that the former are records of values, while the 
latter are polymorphic functions producing records of val¬ 
ues. However there are well-known isomorphisms which we 
can use to construct maps between the two types, namely 
the distributivity laws 

t —> {m, :: t»} <-► {mi :: t —> t;} 

So we have 

Va.~Cj~Oj -* {. mi :: rj <-► {m; :: Va.C~^~ -► tJ 

This is a result in our variant of F w , but not in Haskell 
yet—not all F UJ types can be represented in Haskell. In par¬ 
ticular, the argument types we must push under the record 
type constructor correspond to dictionaries, and hence to 
contexts in Haskell—that is, they cannot be represented as 
parameters of Haskell functions. Luckily, however, methods 
in Haskell 98 can have local contexts in addition to the con¬ 
text of the instance declaration, and the prenex universal 
quantification on method types corresponds exactly to the 
quantification in the type on the right hand side. 

3. A REPRESENTATION IN HASKELL 98 

Returning to Haskell, suppose we have a class declaration 
class Ca where m» :: ctxi U, 

and in the context of some instance declaration we need 
the quantified constraint V6. ctx' => C (ft), where the type 
variable b appears in ctx' and the type f: 

instance (Vb. ctx' => C(ft), ctx") =4> C t' where 



We introduce a “functorial class” CL/ declared as 
class CL// where rmfi :: Wb. [/ t/ a ]((ctx', ctxi) => U) 

where [t/a]cty denotes the type obtained by substituting t 
for a in cty; the quantification over b is implicit in Haskell 98 
but shown here for emphasis, while other implicitly quan¬ 
tified variables are not shown. Then we use the constraint 
CL/ / instead of the desired quantified constraint, and we 
use the method names rn^fi instead of m* in the expressions 
in the dynamic scope of this constraint, e.g. 

instance (CL//, ctx") W : C t' where 
m'j - [m-fi/mt\ei 

This syntactic transformation is in general non-local: The 
requirement to cover the dynamic scope of the constraint im¬ 
plies that all overloaded functions with the constraint C a in 


the type, instantiated with /1 for a in applications reachable 
from ej , must be cloned, and the names of these functions 
and mi substituted by their clones’ names in the cloned code. 

We also provide instances of the form 

instance CL/ T where m_/, = m; 

for each type constructor T for which we would need an 
instance of the desired quantified constraint. The methods 
in these instances are (modulo the type isomorphisms of 
Section 2) essentially trampolines to the defined as usual 
methods in instances of C for applications of T. 

Although we omit the kind specifications of type variables 
for brevity, it should be clear that this transformation is 
valid for arbitrary consistent kinds; however different “func¬ 
torial classes” must be provided for type constructors of dif¬ 
ferent kinds. Since this scheme supports the cases when the 
type t in the quantified constraint V6. ctx' => C (ft) is not 
simply the variable b, if the constraints V6. ctxi =>■ C (fiti) 
and V&. ctx2 => C (/j t2) are both needed in instance dec¬ 
larations, and fi =£ t2, we would have different “functorial 
classes” for them; this is also the case in particular when the 
kinds of ti and t2 (hence of /i and /2) are different. 

In the example of the GRose type in the introduction, 
Hinze and Peyton Jones suggest the use of the quantified 
constraint Va. Binary a => Binary (/ a) to define an in¬ 
stance of Binary. We instead declare the class 

class Binary-f / where 

showBin-f :: Binary a => / a —> [Bit] 

Then an instance of Binary can be constructed for GRose 
as follows: 

instance (Binary a, Binary _/ /) 

=> Binary (GRose / a) where , . 

showBin (GBranch x xs) = ' ' 

showBin x -H- showBin _/ xs 

Additionally, for the construction of Binary instances for 
GRose [ ] Bit we need also the declaration 

instance Binary _/ [ ] where 

showBinJ = showBin 

assuming we already have the instance Binary [o], shown in 
the introduction. 

The simplicity of the auxiliary declarations is due to the 
type inference and dictionary conversion, which automati¬ 
cally insert the type and dictionary applications. As an il¬ 
lustration, the translation of the above code into a variant of 
F u is shown in Figure 1; the calculus is enriched with pattern 
matching on function arguments and a fixpoint expression 
rec x :: r =t e lo allow the translation of recursive instances, 
and we assume the standard definitions of List, concat, map, 
append, and Bit are available. Note that the definition 
of Binary-f-List implements half of the isomorphism be¬ 
tween Binary-f f and V a. Binary a —> Binary (fa), while 
the other half is inlined in the last three lines of the figure 
and evident in the order of the selection from and applica¬ 
tions of df. (An implementation based on Hinze and Peyton 
Jones’ proposal would just avoid these shuffles.) 

This approach, however, is limited by the non-local as¬ 
pects of the transformation. To apply it, we must be able 
to locate and clone statically all functions which are invoked 
from the translated instance declaration and have types with 
the constraints we are replacing. Since Haskell 98 does not 




Binary ::*—>* 

= A a :: *. {showBin :: a —> List Bit} 

BinaryJ ::(*—►*)—>* 

= A/ :: * —► *. 

{showBinJ :: Va. Binary a —> / a —> List Bit } 
Binary_List :: Va Binary a —> Binary (List a) 

= A a :: *. Ad a :: Binary a. 

-[showBin = Xxs :: List a. 
concat [Bit] 

(map [a] [List Bit] ( d a .showBin ) zs)} 

Binary-f-List :: Binary _/ List 

= {showBin-f = Aa :: *.Xd a :: Binary a. 

(Binary-List [a] d a ).showBin } 

Binary-GRose-type :: * 

= Va. V/. Binary a —* Binary-f f —> Binary (fa) 
Binary-GRose :: Binary-GRose-type 
= rec d :: Binary-GRose-type 
= Aa. A/. Ad a . Ad/. 

{.showBin = 

X(GBranch (x :: a) (ss :: f (GRose f a))), 
append [Bit] 

(d a .showBin x) 

(df .showBin J [GRose f a] 

(d[a][f]d a df) 

xs)} 


Figure 1: Translation of instances of Binary. 


allow constraints to be nested in types, it may appear that 
these functions are not first class, hence their invocations 
are always direct and their reachability can be determined 
statically. This is not the case, because these functions may 
be methods of another class; then their types may contain 
constraints, 3 and their invocations are not only indirect— 
they are invisible in the Haskell code. Consider the types 
Sq and Two, introduced earlier. Defining an instance of 
Binary for Sq is now straightforward by replacing the quan¬ 
tified constraint on / with Binary-f f. We must then define 
an instance of Binary-f for Two f under the assumption of 
Binary-f f. However, this is impossible, because (following 
the algorithm) we need to replace with Binary-f f the con¬ 
straint Binary a in the type of showBin _/ in the assumed 
instance Binary-f f, which cannot be determined statically. 

4. A MORE FLEXIBLE APPROACH 

Suppose we also need an instance of Binary for the type 
GRose (GRose []) Bit. To satisfy the constraints in decla¬ 
ration (1), we have to declare an instance of Binary-f for 
GRose []. Naturally we can obtain it from the more general 

instance Binary-f f => Binary-f (GRose f) where 
showBin-f = showBin 

Just as in the case of lists above, this definition exploits the 
existence of an instance of Binary for GRose f a. However 
we have to provide these (trivial) declarations, each defin¬ 
ing showBin-f in terms of showBin, for each type construc- 

3 Ironically this is exactly the Haskell feature that made pos¬ 
sible the approach in the first place. 


tor required to satisfy the quantified constraint encoded by 
Binary-f, and as we showed they introduce a major weak¬ 
ness, because their invocations cannot be replaced statically. 

An alternative is to define showBin in terms of showBin-f 
(to illustrate this we have to ignore the code shown above, 
including and following (1), as well as the earlier instance 
declaration for Binary [a]). It turns out that a single decla¬ 
ration suffices: 

instance (Binary a, Binary-f f) => Binary (f a) where 
showBin = showBin-f 

Unfortunately, due to the type variable / in the head of the 
instance type, this declaration is not in Haskell 98; however, 
at least two implementations support extensions allowing 
such declarations. The list type constructor is now handled 
by one additional declaration: 

instance Binary-f [ ] where 

showBin-f = concat . map showBin 

An analogous declaration would do it for GRose, but its 
kind suggests that a more general definition is useful: 
class Binary-f3 (g ::(*—>*)—>*—> *) where 

showBin-fS :: (Binary a, Binary-f f) =>■ g f a —> [Bit] 
instance (Binary-f (f :: * —> *), BinaryJ3 g) 

^ Binary-f (g f) where 
showBin-f = showBin-f3 
instance BinaryJ3 GRose where 

showBin-f3 (GBranch x xs) = showBin x -H- showBin xs 

The kind annotations are shown for clarity, but they are 
inferred unambiguously. The strong similarity between the 
instance declarations for Binary-f (g f) and Binary (fa), as 
well as those for other function kinds, cannot be taken ad¬ 
vantage of in Haskell, because they refer to classes with dif¬ 
ferent (names and) types of methods. 4 On the other hand 
we only have to define one class and one instance for ev¬ 
ery kind of type constructor for which we need instances of 
Binary, and its subkinds (i.e. syntactic subterms of the kind 
expression), and in a typical Haskell program their number 
is very small. 

With this approach the type Sq, shown in the introduc¬ 
tion, is just as easy to handle: 

instance Binary-f3 Two where 
showBin-f3 (Two x) = showBin x 
instance Binary-f3 Sq where 

showBin-f3 (M x xs) = showBin x -H- showBin xs 
showBin-f3 (E s) 'St showBin s 

In another example, that of an “exponential” type 
data T f a = Aa(fa) \ T (T f (T f a)) 

the encoding works together with Haskell’s recursive in¬ 
stances: 

instance Binary-f3 T where 

showBin-f3 (A x xs) = showBin x -H- showBin xs 
showBinJ3 (T u) = showBin u 

The syntax of quantified constraints allows for an empty 
list of premises, as in for instance Va. C (f a). A case when 

4 An extension of Clean which allows sharing the code for 
such instances is presented in [1]; it can be supported by 
compiling to the language of [3]. 





this sort of constraint is useful was demonstrated by Ashley 
Yakeley in [10]: The class of bifunctors 

class Bifunctor f where 

bimap :: (a —> a') —» (6 —► b') —> / a' b —> fab' 

can be synthesized from the classes of functors and cofunc- 

class Functor f where - - standard 
fmap :: (a -*• 6) -f fa -> fb 
class Cofunctor2 f where 

comap2 :: (a —* a ') —> / a' b —> fab 

if one could write the instance declaration 

instance ( Cofunctor2 f, Va. Functor (fa)) 

=> Bifunctor f where 
bimap fa fb = comap2 fa . fmapfb 

Following the approach, we write instead 
class Functorj / where 
fmapj :: (a -> a') -> /6a -> fba' 
instance Functorj / =4> Functor (f a) where 
fmap = fmapj 

instance ( Cofunctor2 f, Functor j f) 

=> Bifunctor f where 
bimap fafb = comap2 fa . fmap fb 

which completes a program valid in Haskell with extensions 
for variable head instances and overlapping instances. 

5. RELATED WORK 

Ralf Hinze and Simon Peyton Jones describe in [4] the 
utility of quantified constraints in the context of automatic 
derivation of instances. They propose extending the lan¬ 
guage with quantified constraints, and provide semantics for 
the extension. Artem Alimarine and Rinus Plasmejier [1] 
present extensions to Clean, which allow the use of induc¬ 
tion on the structure of kinds in the definition of classes and 
instances in the style of [3]. 

In contrast the simulations outlined in our paper are not 
intended as a substitute for a language extension for the 
purpose of providing compiler support for other features (for 
example automatic instance derivation), although our sec¬ 
ond approach can be used as a basis for a preprocessor. Our 
goal is to offer a solution for problems involving a limited 
set of kinds, for which it is feasible to code the required class 
and instance declarations. Such problems, requiring quanti¬ 
fied constraints, have been discussed multiple times on the 
Haskell mailing lists in recent years. Conor McBride [7] 
has independently outlined the essence of the solution pre¬ 
sented here; unfortunately subsequent discussions on the 
same topic indicate that his description was not interpreted 
to suggest a solution within the existing language. 

6. CONCLUSION 

Of the two presented approaches to simulating quantified 
constraints, the first has the advantages that it can be used 
in Haskell 98, and it does not require changes in the way 
instances of the original classes are constructed. However its 
dependence on the ability to perform (a restricted form of) 
flow analysis of the program prevents it from handling some 
cases of irregular types. The second approach requires an 


extension of Haskell allowing a type variable in the head of 
an instance declaration, and forces some changes in the style 
of coding of instances; in return it is much more flexible. 
While not a substitute for a language extension, the second 
approach appears quite useful in solving typical problems 
involving quantified constraints. 
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